Verified the implementation end-to-end. The shape is right and the precedence rules are well-tested.

What's right

• Type vocabulary matches esbuild (boolean | 'inline' | 'linked' | 'external' | 'both'). Users can pass through whatever esbuild accepts without the SDK getting in the way.
• Precedence is correct and tested: explicit config.sourcemap > WORKFLOW_SOURCEMAP env > per-call-site default. The 10 new tests in resolve-sourcemap.test.ts cover every branch including the env-var aliases (0/1/true/false), unrecognized values (warn + fall through), and the sourcemapsEnabled derived getter. All 145 builders tests pass on the branch.
• sourcemapsEnabled is the right primitive for downstream decisions like skipping the source-map-support runtime shim (vercel-build-output-api.ts:86). That shim isn't trivial in size, so dropping it for sourcemap: false is a meaningful chunk of the 250MB savings.
• Backwards compat preserved: the legacy WORKFLOW_EMIT_SOURCEMAPS_FOR_DEBUGGING=1 keeps working as the per-call-site default for the wrapper/webhook bundles. The "minor semantics change" the changeset flags (explicit sourcemap: ... now overrides the legacy env for those bundles too) is the right resolution — it's the natural meaning of "explicit > env > default" — and the changeset is upfront about it.
• Discover-phase sourcemap: false at line 295 is left untouched. That's correct — write: false means the discover pass doesn't emit anything, sourcemaps would be wasted compute.
• Plumbing is consistent across all five framework adapters (Astro, NestJS, Next.js, Nitro, SvelteKit) — same option name, same type, same docs blurb pattern. Nuxt flows through to Nitro transitively (no separate plumbing needed since Nuxt is already a thin wrapper), so its absence from the changeset is correct.
• CLI works via env var route — WORKFLOW_SOURCEMAP=false workflow build works without any CLI plumbing because all builders inherit BaseBuilder.resolveSourcemap. So the CLI/express/fastify/hono getting-started paths can use this without an additional config layer.
• Documentation is comprehensive: every framework getting-started page that shows config gets a sourcemap row, plus a dedicated "Source maps" section in with-workflow.mdx covering all the modes, the size-vs-stack-trace tradeoff, and the env var precedence.

Nits (non-blocking)

• Type duplication. SourcemapMode is exported from @workflow/builders/types.ts but then redefined inline in 6 places (the framework adapter types and a couple of doc strings). All five framework packages already depend on @workflow/builders, so they could just import type { SourcemapMode } and reuse. If the union ever grows (e.g. esbuild adds a new mode), all 6 sites have to be updated in lockstep. Trivial cleanup, would also DRY up the doc comments which are nearly identical.
• @workflow/nuxt getting-started docs don't mention sourcemap even though it flows through to Nitro and works. The nuxt.mdx page doesn't have a config-options table at all currently, so this isn't a regression — but consider adding parallel coverage for completeness.
• parseSourcemapEnv warning writes directly to console.warn. Most of the codebase uses the structured runtimeLogger for this kind of thing. Probably fine for build-time warnings but worth aligning if there's a builder-side logger.

Tested

• pnpm vitest run packages/builders/src/resolve-sourcemap.test.ts → 10/10 pass.
• pnpm test in packages/builders → 145/145 pass.

LGTM.